C a s e S t u d y Using the New Novell Netware Workstation VLMs February 14, 1994 _________________________________________________________________ Overview -------- We recently installed a Netware 3.12 network, which came with the new Netware Virtual Loadable Modules (VLMs) for workstations. While the installation of the server and backbone LAN went smoothly, the configuration and satisfactory operation of the VLM workstations proved otherwise. We wish to share our initial experience with VLMs with you, so that you may benefit from what we have learned. We would appreciate any response you may offer. Who We Are ---------- My group designs, installs and supports relational database management systems and related custom software applications for client/server environments. To ensure an appropriate server and network platform for these applications, we necessarily design, install and support Novell-based LANs, and WANs. Initial Problems With All VLM Workstations at This Site ------------------------------------------------------- All workstations at the subject site are either PS/2s or AT machines running either DOS 5.0 or 6.0. All are VGA or SVGA machines, and the AT machines are mouse-equipped. In summary, the VLM workstations were simply unstable. Here is an outline of the problems we encountered at the startup of operations. ACCOUNTING SYSTEM: The vendor of this accounting system emphasized the importance of correct FILES= settings in the CONFIG.SYS of the workstation, and for FILES HANDLES for Novell, to ensure stability. (Unfortunately, the vendor was still in the Netware 2.X era regarding FILES HANDLES.) Nonetheless, we ensured that each workstation had sufficient FILES resources to avoid any problem here. Even so, workstations would freeze, especially when printing within the accounting system. RDBMS: Accessing HELP menus at the workstation, especially for script editing, caused the workstation to freeze and/or to "zap" some TSRs. We also encountered "record lock" conditions, followed by a loss of network connection. RCONSOLE: "IPX Open Socket Failed" at loss of network connection. PRINT SCREEN: The workstation would freeze. LANSIGHT: Screen images were contaminated, and we would lose the USER TSR. First a Brief Tutorial on Workstation Setup with VLMs ----------------------------------------------------- For reasons wholly our own, we standardize on Hewlett- Packards "16+" LAN cards. This site has a combination of PS/2s and AT machines, but we will only address the AT machines. If you want additional information on the setup of the PS/2s, we can provide it. There are two steps in setting up a VLM workstation. [1] Use the setup disk which comes with the LAN card, and configure the card in the workstation. Write down the following settings at the conclusion of the card setup, as you must specify these when installing the VLMs. PORT = DMA = INT = FRAME TYPE = Note: The default Frame type for VLMs is 802.2, NOT 802.3. Make sure you have the right frame type for your network. [2] Use the WorkStation Setup disk and DOS/AT disk which comes with the Netware disks to configure and install the VLMs. These do the following. [a] Create the directory NWCLIENT on the workstation hard drive. [b] Create a NET.CFG file located in the NWCLIENT directory, which contains the precise configuration information for each workstation. (With more and more components on PCs, chances are each workstation setup will be different, so dont count on simply copying the first setup into other workstations.) [c] Add the line LAST DRIVE = Z to the CONFIG.SYS file. [d] Add the line @CALL C:\NWCLIENT\STARTNET.BAT to the AUTOEXEC.BAT file. The STARTNET.BAT file loads all files and drivers needed to connect the workstation to the network. A typical STARTNET.BAT file looks like this. @echo off c: cd \nwclient set nwlanguage=english lsl ipxodi vlm cd \ It uses a file called NET.CFG from the NWCLIENT directory for configuration information. A typical NET.CFG file looks like this. Note that the indentation is essential. Link Driver AM2100 <- card driver name PORT 300 DMA 3 INT 10 FRAME Ethernet_802.3 Netware DOS Requester FIRST NETWORK DRIVE = F USE DEFAULTS = OFF VLM = CONN.VLM VLM = IPXNCP.VLM (etc) VLM = NETX.VLM Now to the Problems, Causes and Remedies ---------------------------------------- The root problem with VLMs, as you may have begun to suspect, is that they consume much more conventional memory in DOS machines than the traditional network shells. In any robust environment, this will likely cause certain applications to seize memory, zapping TSRs and network drivers, knocking the workstation off the network, and ultimately freezing the workstation when they run out of memory. THEREFORE, you MUST have a memory management capability, such as QEMM or DOS 6.0/6.2s MemMaker, if you are even to attempt running VLMs successfully. FURTHER, you may find that some machines simply will not run with the VLMs, no matter how hard you try. If so, you can usually trace this to an inherent conflict between the LAN card, BIOS or bus controller on the motherboard and the memory management system you are attempting to use. Unless you are willing to replace the PC, you will need a "blended" solution, as described below. VLMs and Memory Management -------------------------- There are three major issues to address when you tackle VLMs and memory management. [1] How much conventional memory you must free up will depend on the mix of applications running on your network and workstations, and their various "minimum" workstation conventional memory needs. Regrettably, these are not always evident. A good rule of thumb is that you should have 550K or more of conventional memory when you are done. If you have below 500K, you will likely have problems. [2] What mix of TSRs, system drivers and network drivers you can successfully load into and execute properly from upper memory blocks (UMBs) will depend on each PC. They are NOT all alike, and even the same "brand" works differently with different CPUs/speeds, etc. (Here, too, you can trace these differences to versions of motherboards, etc.) A network driver comfortable in upper memory on one machine will not load into an UMB on the next, and so on. [3] The STARTNET.BAT file is embedded in the AUTOEXEC.BAT file. QEMM will not even attempt to optimize the workstation and network drivers here. We successfully tricked QEMM by first moving the STARTNET command lines into the AUTOEXEC.BAT, then optimizing, then copying the results back into the STARTNET.BAT file. (We did not try MemMaker, as we moved next to the solution described below.) What To Do If You Have Problems with VLMs ----------------------------------------- First of all, do your best to ensure the problem(s) you encounter are related to the VLMs. To illustrate, we moved the customers accounting system onto the network. While testing the entry of a payments batch in the accounts payable module, it appeared during the printing of the trial batch that while the batch total was correct, the detail records were lost. We first suspected this was caused by known bugs in the VLMs which show up during network printing. It turned out that this was caused instead by an unpublicized bug in the LAN pack from the accounting system vendor, and an installable patch from them fixed this problem. By all means, call Novells technical support group. They are a breath of fresh air compared to other tech (un)support groups. Those of you who fight the battles we fight every day know from whence we speak. If the problems you find surround printing on the network, try Novells VLM update. You can download this self-extracting file, called VLMUP.EXE, from Novells BBS, explode it in a temporary directory, and follow the README instructions. These files contain BETA (at this writing) VLM changes to overcome listed problems with the Netware Client for DOS/Windows. We tried this, and while it improved the workstation performance somewhat, it didnt solve our particular problems. Given the machine types at our installation site, we were unsuccessful in combining VLMs, memory management and applications. Our solution was to fall back completely to Netware ODIs. You may find that VLMs work fine on some machines, while the following ODI solution may be required on others. We obtained the latest from Novells BBS, by pulling down a self-extracting file called DOSUP8.EXE. (We believe DOSUP9.EXE is now the latest.) This file was copied into a DOSUP8 directory on the server, and exploded. Then, we took the following steps with each workstation. [1] We created the local hard drive directory C:\LAN. [2] We copied the following files from the DOSUP8 directory into C:\LAN. LSL.COM IPXODI.COM NETX.EXE [3] We copied the LAN card driver to this directory. In this case, the name of the LAN card driver was "AM2100.COM". [4] Using DOS Editor, we created a NET.CFG file, which contained the following. Note that the indentation starting with Line 2 is required. Link Driver AM2100 PORT 300 DMA 5 INT 10 FRAME Ethernet_802.3 [5] When we finished, the C:\LAN directory contained the following files. AM2100.COM IPXODI.COM LSL.COM NETX.EXE NET.CFG [6] Next, we edited the AUTOEXEC.BAT file, and added these lines. Note that the order is essential. C:\LAN\LSL C:\LAN\AM2100 <- the card driver C:\LAN\IPXODI C:\LAN\NETX [7] Then, we used either QEMM or MemMaker to optimize memory, depending on the workstation, and tested each workstation to ensure that whatever the memory manager loaded into UMBs was stable. If a workstation was not completely stable, we customized its memory optimization until everything worked in concert. [8] Finally, we created a directory and subdirectories for each workstation on the server, and copied the contents of each LAN directory and associated CONFIG.SYS and AUTOEXEC.BAT into these subdirectories. (Who wants to try to remember which configuration worked with which workstation?!?) Conclusions ----------- While we wish otherwise, we are stuck with the apparently never-ending battle of DOS conventional memory limitations and conflicting hardware and software solutions. Hopefully, this case study lends some useful insight, and helps some of you "make it work". Your responses, critiques and questions will be welcomed.